03. Other Types of Technical Safety Requirements

ISO 26262 Definition of Latent Faults

A more rigorous definition of latent faults from ISO 26262 reads:

multiple-point fault (3.96) whose presence is not detected by a safety mechanism (3.141) nor perceived by the driver within the multiple-point fault detection time interval (3.97)

Faults External to the Lane Keeping Item

We mentioned that a possible technical safety requirement for an external fault could be for code that checks communication errors between the anti-lock brake ECU and the power steering ECU. The anti-lock brake ECU might share vehicle speed data with the power steering ECU. We are not going to expand on this example in the rest of the lesson. But if you want to challenge yourself, consider expanding on this idea in the final project.

Imagine that the lane keeping assistance function does not take driver speed into account when deciding how much torque to apply. This could lead to a potentially hazardous situation where the system turns the wheel too abruptly at a high vehicle speed. Or the lane keeping assistance provides too much extra torque on a sharp curve. The driver could lose control of the vehicle. So this idea could be part of a hazard and risk analysis, which would lead to a safety goal. Then you'd derive functional safety requirements from the safety goal. And finally you'd derive technical safety requirements from the functional safety requirements.

More Technical Safety Requirements

Soon it will be your turn to identify technical safety requirements! In the project, you will be responsible for deriving technical safety requirements for the other two functional safety requirements.

The other two functional safety requirements were:

"the electronic power steering ECU shall ensure that the lane departure warning oscillating torque frequency is below Max_Torque_Frequency".

"the lane keeping assistance function shall be time limited and the additional steering torque shall end after a given timer interval so that the driver can not misuse the system for autonomous driving".

You will use the examples we've already given as a guide for deriving technical safety requirements. The truth is, most of the technical safety requirements already derived would also be relevant to the two other functional safety requirements. You might have to change variable names or architectural element names.

Remember that some technical safety requirements can be derived directly from a functional safety requirement; other technical safety requirements will fall under the five categories described in the above video.

Methods for Checking Data Validity and Integrity

One of the technical safety requirements mentioned checking the data validity and integrity of the data transmission: "The validity and integrity of the data transmission for LDW_Torque_Request signal shall be ensured."

To check data validity and integrity, you can add a CRC (cyclic redundancy check); a CRC is a well established methods that looks for changes to raw data. A qualifier can then be added as well, which is a signal indicating whether or not a signal is valid. The CRC ensures the data that is sent out by one element is the same data received by another element.

Another common mechanism is an alive counter. An alive counter checks that the signal is new and not an old signal; an alive counter increases the count every time a signal goes out.

CRCs and alive counters can be used together to guarantee correct transmission. The final lesson on software requirements will also discuss a specific CRC protocol in more depth.